X.509 Path Validation Test Suite, Version
1.07 enabling tools for PKI client software
developers
This page contains conformance tests
for relying parties that validate X.509 certification paths.
Each test consists of a set of X.509 certificates and CRLs.
The tests are fully described in the Conformance
Testing of Relying Party Client Certificate Path Processing
Logic document. The goal for the first release of these
tests was to address the X.509 features used in the DoD Class 3
PKI. Additional features will be added in the future.
The
tests cover X.509 version 3 certificates and X.509 Version 2
CRLs. The tests cover the commonly used fields and extensions
with the following caveats:
- Serial number
is always positive in these tests.
- Distinguished
names only use PrintableString in attributes whose
value is of type DirectoryString (e.g., o=, ou=, or
cn=).
- Unique
identifiers never appear in these certificates.
- All
certificates are signed with RSA PKCS
#1 v1.5 and SHA-1.
- At a minimum,
implementations must support basic constraints and key
usage. If these extensions are not supported, the
implementation will not be able to process any of the
tests.
- These tests
also address certificate policies and policy constraints.
Tests for policyConstraints address only the requireExplicitPolicy
field.
- Expected test
results assume that the implementation requires certificate status
information and processes CRLs.
The tests are provided in
three different formats:
- as a compressed
tar file. This file may be opened using tar or
WinZip. To use tar, the command "tar -zxvf
<filename>" will decompress and untar the file. This
will create a folder called "X509tests", which will in turn
contain 76 folders called "testX" where X is "1" through
"76".
- as a zip
file. This file may be opened using unzip or
WinZip. This will create a folder called "X509tests", which
will in turn contain 76 folders called "testX" where X is "1"
through "76".
- as a self-extracting
executable file. The executable will run on Windows and
will create 76 folders called "testX", where X is "1" through
"76", in the directory specified by the user.
In all three
cases, each folder contains all the certificates and CRLs required
to perform one of the tests, as well as the end entity private
key. The tests are ordered in the same way as they are ordered
in the document that describes the tests. In cases where the
API for the path validation routines is not exposed, the private key
may be used with applications to implement these tests.
Each folder contains five
types of files:
- Files with a
"crt" extension contain certificates.
- Files with a
"crl" extension contain CRLs.
- Files with a
"p12" extension are encoded according to PKCS
#12 and contain encrypted versions of the end entity private
keys (the password for each .p12 file is "password"). In
addition, each .p12 files contains a CertBag and a
CRLBag that together include all of the
relevant certificates and CRLs for the test.
- Files with a
"p7m" extension contain signed S/MIME
messages (i.e., CMS) that may be useful in testing the path
validation capabilities of S/MIME clients. Each .p7m
contains a message that was signed using the end entity's private
key. As with the .p12 files, the .p7m files also include all
of the certificates and CRLs for the test.
- Files with a
"crtx" contain private keys. The syntax of the these files
is according to the PrivateKeyInfo data structure in PKCS
#8, where the OCTET STRING for privateKey
contains a DER encoded RSAPrivateKey from PKCS
#1.
The certificates and CRLs
necessary to perform the tests can also be retrieved using
LDAP. The direcotry is on the machine seclab7.ncsl.nist.gov
(129.6.20.35) and can be accessed using port 389. The schema
specified in RFC 2587 was used to place the certificates and CRL in
the directory.
Notes: The trust anchor and CRL are included in each
test. However, the same trust anchor and CRL are used for
every test. It may be more convenient to establish the trust
anchor and then perform the tests.
The certificates and CRLs are signed with the same Certification
Authority (CA) using the same private key. Thus, the issuer
Distinguished Name (DN) in the certificate and the issuer DN in the
CRL will always match. Furthermore, there is no need to
develop a certification path for validating signatures on the
CRL. In fact, the same public key used to validate the
signature on a certificate MUST be used to validate the signature on
the CRL.
The X.509 2000 policy processing rules are assumed.
No test data has changed between versions 1.06 and 1.07 of this
test suite. All of the tests and expected test results are the
same. The only changes in version 1.07 are minor corrections
in the documentation. |